<?php
/**
 * <https://y.st./>
 * Copyright © 2017 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'Another Alex',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<img src="/img/CC_BY-SA_4.0/y.st./weblog/2017/09/24.jpg" alt="Strange seeds on a plant by the road" class="framed-centred-image" width="800" height="480"/>
<section id="general">
	<h2>General news</h2>
	<p>
		I met a new coworker today, someone that shares my name.
	</p>
</section>
<section id="university">
	<h2>University life</h2>
	<p>
		I began one of my discussion assignments today:
	</p>
	<blockquote>
		<p>
			The operating system can&apos;t actually decide to switch processes when a process is running, as that process occupies the $a[CPU].
			As the $a[CPU] can only run one process at a time, the operating system process can&apos;t be running when the application process is running.
			Depending on the hardware, the operating system has a couple of options at its disposal.
			With hardware support, a timer can be set to interrupt running programs at a particular frequency, switching control back to the operating system (Arpaci-Dusseau &amp; Arpaci-Dusseau, 2016).
			At this point, the operating system can perform whatever actions it needs to, such as switching between applications.
			Without hardware support though, the operating system is stuck relying on the application to willingly hand control back to the operating system every so often.
			As the application has no hard requirement to do this, such reliance requires a lot of trust and can result in the application preventing the operating system from running again if that trust is broken.
		</p>
		<p>
			Once the operating system has regained control, switching processes is easy.
			The state of the previously-running application is saved, then the state of the soon-to-be-executed program is loaded.
			(This state includes the registers and the kernel stack pointer, among other things.)
			When the operating system returns from the trap, the hardware will then run the software associated with the newly-loaded registers instead of continuing with the application that it&apos;d just been running (Arpaci-Dusseau &amp; Arpaci-Dusseau, 2016).
		</p>
		<p>
			The operating system uses the scheduler to decide what process to run, but the algorithm used by the scheduler can be different between systems.
			Modern systems use variations of an algorithm called the multi-level feedback queue.
			In this algorithm, the scheduler has several queues instead of a single one, and each queue has a different priority level.
			When processes relinquish control to the system frequently, they&apos;re kept in a higher-priority queue, but if they run long, $a[CPU]-intensive operations, they&apos;re bumped down to a lower queue.
			When a process is created, it&apos;s put in the highest-priority queue.
			Any time it returns to the system before using up its entire allotted $a[CPU] time slice, that process is left in its same queue.
			However, the $a[CPU] time consumed isn&apos;t reset.
			When the process is next run, the amount of used run time in the current slice is added to the amount of $a[CPU] time the process already consumed.
			Any time the process uses the entire $a[CPU] time slice provided, or has used a total $a[CPU] time above a certain threshold, the process gets bumped down to a lower-priority queue, unless it&apos;s already in the lowest queue, in which case it stays put.
			No job will run if there&apos;s a job that exists in a higher-priority queue; high-priority queue jobs are run first.
			If multiple processes exist in the same queue, they&apos;ll be processed in a round-robin-like manner.
			To prevent $a[CPU]-intensive processes from getting starved by several high-priority processes, all processes can be bumped to the highest-priority queue every so often, on a schedule (Arpaci-Dusseau &amp; Arpaci-Dusseau, 2016).
		</p>
		<div class="APA_references">
			<h2>References:</h2>
			<p>
				Arpaci-Dusseau, R. H., &amp; Arpaci-Dusseau, A. C. (2016, July 20). Mechanism: Limited Direct Execution. Retrieved from <a href="http://pages.cs.wisc.edu/~remzi/OSTEP/cpu-mechanisms.pdf"><code>http://pages.cs.wisc.edu/~remzi/OSTEP/cpu-mechanisms.pdf</code></a>
			</p>
			<p>
				Arpaci-Dusseau, R. H., &amp; Arpaci-Dusseau, A. C. (2016, July 20). Scheduling: The Multi-Level Feedback Queue. Retrieved from <a href="http://pages.cs.wisc.edu/~remzi/OSTEP/cpu-sched-mlfq.pdf"><code>http://pages.cs.wisc.edu/~remzi/OSTEP/cpu-sched-mlfq.pdf</code></a>
			</p>
		</div>
	</blockquote>
</section>
END
);
